Stream: Independent Submission 


RFC: 9192 

Category: Informational 

Published: February 2022 

ISSN: 2070-1721 

Authors: T. Mizrahi  ILYerushalmi D. Melman R. Browne 
Huawei Marvell Marvell Intel 


RFC 9192 
Network Service Header (NSH) Fixed-Length Context 
Header Allocation 


Abstract 


The Network Service Header (NSH) specification defines two possible methods of including 
metadata (MD): MD Type 0x1 and MD Type 0x2. MD Type 0x1 uses a fixed-length Context Header. 
The allocation of this Context Header, i.e., its structure and semantics, has not been standardized. 
This memo defines the Timestamp Context Header, which is an NSH fixed-length Context Header 
that incorporates the packet's timestamp, a sequence number, and a source interface identifier. 


Although the definition of the Context Header presented in this document has not been 
standardized by the IETF, it has been implemented in silicon by several manufacturers and is 
published here to facilitate interoperability. 


Status of This Memo 


This document is not an Internet Standards Track specification; it is published for informational 
purposes. 


This is a contribution to the RFC Series, independently of any other RFC stream. The RFC Editor 
has chosen to publish this document at its discretion and makes no statement about its value for 
implementation or deployment. Documents approved for publication by the RFC Editor are not 
candidates for any level of Internet Standard; see Section 2 of RFC 7841. 


Information about the current status of this document, any errata, and howto provide feedback 
on it may be obtained at https://www.rfc-editor.org/info/rfc9192. 
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1. Introduction 


The Network Service Header (NSH), defined in [RFC8300], is an encapsulation header that is used 
as the service encapsulation in the Service Function Chaining (SFC) architecture [RFC7665]. 


In order to share metadata (MD) along a service path, the NSH specification [RFC8300] supports 
two methods: a fixed-length Context Header (MD Type 0x1) and a variable-length Context Header 
(MD Type 0x2). When using MD Type 0x1, the NSH includes 16 octets of Context Header fields. 
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The NSH specification [RFC8300] has not defined the semantics of the 16-octet Context Header, 
nor does it specify how the Context Header is used by NSH-aware Service Functions (SFs), Service 
Function Forwarders (SFFs), and proxies. Several Context Header formats are defined in [NSH- 
TLV]. Furthermore, some allocation schemes were proposed in the past to accommodate specific 
use cases, e.g., [NSH-DC-ALLOC], [NSH-BROADBAND-ALLOC], and [RFC8592]. 


This memo presents an allocation for the MD Type 0x1 Context Header, which incorporates the 
timestamp of the packet, a sequence number, and a source interface identifier. Note that other 
allocation schema for MD Type 0x1 might be specified in the future. Although such schema are 
currently not being standardized by the SFC Working Group, a consistent format (allocation 
schema) should be used in an SFC-enabled domain in order to allow interoperability. 


In a nutshell, packets that enter the SFC-enabled domain are timestamped by a classifier 
[RFC7665]. Thus, the timestamp, sequence number, and source interface are incorporated in the 
NSH Context Header. As discussed in [RFC8300], if reclassification is used, it may result in an 
update to the NSH metadata. Specifically, when the Timestamp Context Header is used, a 
reclassifier may either leave it unchanged or update the three fields: Timestamp, Sequence 
Number, and Source Interface. 


The Timestamp Context Header includes three fields that may be used for various purposes. The 
Timestamp field may be used for logging, troubleshooting, delay measurement, packet marking 
for performance monitoring, and timestamp-based policies. The source interface identifier 
indicates the interface through which the packet was received at the classifier. This identifier may 
specify a physical interface or a virtual interface. The sequence numbers can be used by SFs to 
detect out-of-order delivery or duplicate transmissions. Note that out-of-order and duplicate 
packet detection is possible when packets are received by the same SF but is not necessarily 
possible when there are multiple instances of the same SF and multiple packets are spread across 
different instances of the SF. The sequence number is maintained on a per-source-interface basis. 


This document presents the Timestamp Context Header but does not specify the functionality of 
the SFs that receive the Context Header. Although a few possible use cases are described in this 
document, the SF behavior and application are outside the scope of this document. 


Key Performance Indicator (KPI) stamping [RFC8592] defines an NSH timestamping mechanism 
that uses the MD Type 0x2 format. This memo defines a compact MD Type 0x1 Context Header 
that does not require the packet to be extended beyond the NSH. Furthermore, the mechanisms 
described in [RFC8592] and this memo can be used in concert, as further discussed in Section 4.1. 


Although the definition of the Context Header presented in this document has not been 
standardized by the IETE it has been implemented in silicon by several manufacturers and is 
published here to facilitate interoperability. 
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2. Terminology 


2.1. 


Requirements Language 


The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", 
"RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be 
interpreted as described in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all 
capitals, as shown here. 


2.2. 


Abbreviations 


The following abbreviations are used in this document: 


KPI 
MD 


Key Performance Indicator [RFC8592] 
Metadata [RFC8300] 

Network Service Header [RFC8300] 
Service Function [RFC7665] 

Service Function Chaining [RFC7665] 


Service Function Forwarder [RFC8300] 


3. NSH Timestamp Context Header Allocation 


This memo defines the following fixed-length Context Header allocation, as presented in Figure 1. 


0 1 2 3 
0815225315415 056587/2082920810205304105269878829000/100209304058657:58 59 $08 
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
| Sequence Number | 
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
| Source Interface | 
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
| Timestamp | 


+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 


Figure 1: NSH Timestamp Allocation 


The NSH Timestamp allocation defined in this memo MUST include the following fields: 


Sequence Number: A 32-bit sequence number. The sequence number is maintained on a per- 
source-interface basis. Sequence numbers can be used by SFs to detect out-of-order delivery or 
duplicate transmissions. The classifier increments the sequence number by 1 for each packet 
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received through the source interface. This requires the classifier to maintain a per-source- 
interface counter. The sequence number is initialized to a random number on startup. After it 


reaches its maximal value (222-1), the sequence number wraps around back to zero. 


Source Interface: A 32-bit source interface identifier that is assigned by the classifier. The 
combination of the source interface and the classifier identity is unique within the context of 
an SFC-enabled domain. Thus, in order for an SF to be able to use the source interface asa 
unique identifier, the identity ofthe classifier needs to be known for each packet. The source 
interface is unique in the context of the given classifier. 


Timestamp: A 64-bit field that specifies the time at which the packet was received by the 
classifier. Two possible timestamp formats can be used for this field: the two 64-bit 
recommended formats specified in [RFC8877]. One of the formats is based on the timestamp 
format defined in [IEEE1588], and the other is based on the format defined in [RFC5905]. 


The NSH specification [RFC8300] does not specify the possible coexistence of multiple MD Type 
0x1 Context Header formats in a single SFC-enabled domain. It is assumed that the Timestamp 
Context Header will be deployed in an SFC-enabled domain that uniquely uses this Context 
Header format. Thus, operators SHOULD ensure that either a consistent Context Header format is 
used in the SFC-enabled domain or there is a clear policy that allows SFs to know the Context 
Header format of each packet. Specifically, operators are expected to ensure the consistent use of 
a timestamp format across the whole SFC-enabled domain. 


The two timestamp formats that can be used in the Timestamp field are as follows: 


Truncated Timestamp Format [IEEE1588]: This format is specified in Section 4.3 of [RFC8877]. 
For the reader's convenience, this format is illustrated in Figure 2. 


0 1 2 3 

@ 12537455 6 77879-07152 0374 75/6: 7°89 0711273747576. 7-829787 
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- 
| Seconds 
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- 
| Nanoseconds 
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- 


+— +—+4+ 


Figure 2: Truncated Timestamp Format (IEEE 1588) 


NTP 64-bit Timestamp Format [RFC5905]: This format is specified in Section 4.2.1 of [RFC8877]. 
For the reader's convenience, this format is illustrated in Figure 3. 


Mizrahi, et al. Informational Page 5 


RFC 9192 NSH Timestamp February 2022 


0 1 2 3 
OMI 2 3840550560 A O r A e L 546287298 98085082 7384050560 TA e e 08] 
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- 
| Seconds 
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- 
| Fraction 
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- 


+—+—+4 


Figure 3: NTP 64-Bit Timestamp Format (RFC 5905) 


Synchronization aspects of the timestamp format in the context of the NSH Timestamp 
allocation are discussed in Section 5. 


4. Timestamping Use Cases 


4.1. Network Analytics 


Per-packet timestamping enables coarse-grained monitoring of network delays along the Service 
Function Chain. Once a potential problem or bottleneck is detected (for example, when the delay 
exceeds a certain policy), a highly granular monitoring mechanism can be triggered (for 
example, using the hop-by-hop measurement data defined in [RFC8592] or [IOAM-DATA]), 
allowing analysis and localization of the problem. 


Timestamping is also useful for logging, troubleshooting, and flow analytics. It is often useful to 
maintain the timestamp of the first and last packet of the flow. Furthermore, traffic mirroring 
and sampling often require a timestamp to be attached to analyzed packets. Attaching the 
timestamp to the NSH provides an in-band common time reference that can be used for various 
network analytics applications. 


4.2. Alternate Marking 


A possible approach for passive performance monitoring is to use an Alternate-Marking Method 
[RFC8321]. This method requires data packets to carry a field that marks (colors) the traffic, and 
enables passive measurement of packet loss, delay, and delay variation. The value of this marking 
field is periodically toggled between two values. 


When the timestamp is incorporated in the NSH, it can intrinsically be used for Alternate 
Marking. For example, the least significant bit of the timestamp Seconds field can be used for this 
purpose, since the value of this bit is inherently toggled every second. 


4.3. Consistent Updates 


The timestamp can be used for making policy decisions, such as 'Perform action A if 
timestamp>=T_0'. This can be used for enforcing time-of-day policies or periodic policies in SFs. 
Furthermore, timestamp-based policies can be used for enforcing consistent network updates, as 
discussed in [DPT]. It should be noted that, as in the case of Alternate Marking, this use case alone 
does not require a full 64-bit timestamp but could be implemented with a significantly smaller 
number of bits. 
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5. Synchronization Considerations 


Some of the applications that make use of the timestamp require the classifier and SFs to be 
synchronized to a common time reference -- for example, using the Network Time Protocol 
[RFC5905] or the Precision Time Protocol [IEEE1588]. Although it is not a requirement to use a 
clock synchronization mechanism, it is expected that, depending on the applications that use the 
timestamp, such synchronization mechanisms will be used in most deployments that use the 
Timestamp allocation. 


6. IANA Considerations 


This document has no IANA actions. 


7. Security Considerations 


The security considerations for the NSH in general are discussed in [RFC8300]. The NSH is 
typically run within a confined trust domain. However, if a trust domain is not enough to provide 
the operator with protection against the timestamp threats as described below, then the operator 
SHOULD use transport-level protection between SFC processing nodes as described in [RFC8300]. 


The security considerations of in-band timestamping in the context of the NSH are discussed in 
[RFC8592]; this section is based on that discussion. 


In-band timestamping, as defined in this document and [RFC8592], can be used as a means for 
network reconnaissance. By passively eavesdropping on timestamped traffic, an attacker can 
gather information about network delays and performance bottlenecks. An on-path attacker can 
maliciously modify timestamps in order to attack applications that use the timestamp values, 
such as performance-monitoring applications. 


Since the timestamping mechanism relies on an underlying time synchronization protocol, by 
attacking the time protocol an attack can potentially compromise the integrity of the NSH 
Timestamp. A detailed discussion about the threats against time protocols and how to mitigate 
them is presented in [RFC7384]. 
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